The concept of a "transaction" is an abstraction used in reliable computer systems to protect certain resources, such as databases. Fundamentally, a transaction is defined as a unit of work that is 1) "atomic," 2) "consistent," 3) "isolated," and 4) "durable" (more commonly, it is said that transactions have "ACID" properties). To initiate a transaction, an application program performs a "begin transaction" operation. Subsequently, the application program accesses and potentially modifies one or more protected resources. At the end of the transaction, the application program executes either a "commit transaction" or a "rollback transaction" operation.
To be "atomic," a transaction must complete in an all-or-none fashion. This means that protected resources must reflect all changes made between a begin transaction operation and a corresponding following commit transaction operation. Protected resources must also reflect none of the changes made between a begin transaction operation and a corresponding following rollback transaction operation. In addition, a transaction that is interrupted by any failure that interferes with its successful completion is rolled back by the transaction system and the application is informed of this result. Again in this case, protected resources must reflect none of the changes made to them by the rolled-back transaction.
To be "consistent," a transaction must move protected resources from one consistent state to another. More specifically, in systems that use the transaction abstraction, the application program and other systems components that participate in a transaction are allowed to specify integrity constraints. Resource managers may also specify their own integrity constraints. For example, in a product inventory database, a typical application-specified integrity constraint would prevent any transaction that would result in a negative quantity of any product. In a genealogy database, an application-specified integrity constraint might be used to prevent any transaction that would result in a child having more than two genetic parents. To be "consistent," each such integrity constraint must be evaluated before the transaction is committed. If any of the integrity constraints are not met, the transaction must be aborted. In this way, transactions are guaranteed to move protected resources from one consistent state to another.
To be "isolated," the changes made to protected resources must be invisible to threads and processes that are not associated with the transaction until the transaction has committed. Typically, isolation is achieved by locking the changed resource. Application programs that attempt to read the locked resource are forced to wait until the transaction has completed.
Finally, to be "durable," the changes made to protected resources must not be lost or corrupted, even in the case of a catastrophic system failure. In this context, durability is not used in the absolute sense. For example, physically destroying the transaction processing computer system and all of its backup records will violate the durability property.
In most systems that use the transaction abstraction, application programs are prevented from directly accessing protected resources. Instead, a resource manager is provided for each protected resource. Application programs access and modify protected resources by sending messages to the corresponding resource manager. In many cases, a single transaction will involve a number of different resources located on a number of different computer systems. In order to preserve ACID properties in distributed transactions of this type, a two-phase commit protocol is used. In the two-phase commit protocol, a transaction manager is used to coordinate the actions of the resource managers involved in a transaction. The transaction manager is also the final arbiter of whether a transaction has committed or not.
To use the two-phase commit protocol an application program sends a begin transaction message to the transaction manager. In response, the transaction manager creates a unique identifier associated with the transaction. Subsequently, the transaction processing system includes the transaction identifier in all messages sent by the application program until the transaction is committed or rolled back.
After performing the begin transaction operation, the application program may send messages to one or more resource managers to access or modify selected resources. Resource managers so contacted may in turn send messages to other resource managers, and so on. Each resource manager contacted in this fashion sends a registration message to the transaction manager. The transaction manager uses the registration message to add the sending resource manager to a list of resource managers participating in the transaction.
To complete the transaction, the application program sends a commit transaction message to the transaction manager. In response, the transaction manager sends a prepare message to each resource manager that has been registered as participating in the transaction. The prepare message asks each resource manager to vote on the outcome of the transaction. In response to the prepare message, each resource manager sends a message back to the transaction manager. The message must either vote "commit," or "rollback." Resource managers voting to rollback the transaction must undo the changes that have been made to their associated resources and abandon the transaction. Resource managers voting to commit, on the other hand, are promising that they can either commit or rollback the transaction, even if a failure occurs after they have voted.
The transaction manager tabulates all of the votes received from the participating resource managers. If each resource manager votes to commit, the transaction manager records the fact that the transaction has committed on durable storage and sends a commit message to each resource manager. The commit message tells the resource managers to commit the changes that have been made to their associated resources. The commit message also tells the resource managers to expose (i.e., make visible) all of the changes that have been made to their associated resources.
Alternatively, if one or more resource managers votes to rollback, the transaction manager sends a rollback resource managers message to each resource manager. The rollback message tells the resource managers to rollback the changes that have been made to their associated resources. The resource managers respond by undoing the changes that have been made to their associated resources and abandoning the transaction.
The ACID properties of a transaction apply to the protected resources that are located on durable media (e.g., magnetic disks). These same ACID properties do not, however, generally apply to the internal state of processes participating in a transaction. As a result, in the event of a rolled back transaction, the internal state of participating processes may have to be manually reconfigured into a pre-transaction condition, or may be lost altogether. Reconfiguration, when possible, may be both complex and time consuming; loss may be completely unacceptable. As a result, a need exists for methods that protect the internal state of processes involved in transactions.